The Secure Shell (SSH) protocol is one of the most widely used cryptographic protocols today. SSH is frequently used for remote administration, secure file transfers, backups, and process-to-process communication.
The Secure Shell (SSH) protocol is described in the Internet Engieering (IETF) standards RFC 4250, The Secure Shell (SSH) Protocol Assigned Numbers, Internet Engineering Task Force, January 2006; RFC 4251, The Secure Shell (SSH) Protocol Architecture, Internet Engineering Task Force, January 2006; RFC 4252, The Secure Shell (SSH) Authentication Protocol, Internet Engineering Task Force, January 2006; RFC 4253, The Secure Shell (SSH) Transport Layer Protocol, Internet Engineering ask Force, January 2006; and RFC 4254, The Secure Shell (SSH) Connection Protocol, Internet Engineering Task Force, January 2006. They are freely available for downloading at www.ietf.org. The original protocol was invented and developed by the present inventor in 1995-1999, and then standardized by the IETF.
The SSH protocol and related client and server software applications are now included in many Unix and Linux versions, such as IBM AIX, HP-UX, Solaris, Red Hat, SUSE, Ubuntu, etc. Popular implementations of the SSH protocol include the open source OpenSSH, which is based on the present inventor's free SSH version 1.12 from 1995, and the commercial Tectia SSH client and server from SSH Communications Security Corporation.
Some of the largest enterprises in the world have hundreds of thousands of computers and up to about a hundred thousand servers running various versions of Unix, Linux, and Windows operating systems on their network. Large enterprises commonly run thousands of different business applications that interact with each other and transmit data and files to/from each other in an automated fashion. A large enterprise typically has tens of thousands of hosts running SSH servers.
The term “host” means a computer or generally any computing node or apparatus on a network that has its own IP address and/or domain name (though some hosts can be multi-homed, that is, have more than one IP address or more than one domain name). A computer can be any kind of computer, such as general purpose computer, desktop computer, server computer, embedded system, mainframe, mobile device, cluster of computers, or a distributed computer. A host can also be a virtual machine.
An IP network is a network that communicates using the Internet Protocol (RFC 791, RFC 2460, or a later version thereof). An IP address means an IPv4 addresses, an IPv6 addresses, and/or an address for a future communication protocol that can be used for similar purposes. TCP/IP means the Transmission Control protocol (RFC 793), and UDP means the User Datagram Protocol (RFC 768), or a later version thereof.
To automate file transfers and other communication between computers and applications, companies often use public key authentication according to the SSH protocol. Public key authentication and how to set it up is described in RFC 4252 and the books D. Barrett et al: SSH, the Secure Shell: The Definitive Guide, O'Reilly, 2001; H. Dwivedi: Implementing SSH: Strategies for Optimizing the Secure Shell, Wiley, 2004; and A. Carasik: Unix Secure Shell, McGraw-Hill, 1999.
Generally, public key authentication is just one method for implementing passwordless logins. A passwordless login is a mechanism whereby a program running under a user account on a first host can gain access to a second account on a second host (though they could also be the same account and same host), without needing to have an interactive user supply a password, typically to execute a command on the second host or to transfer files to/from the second host. Other known mechanisms for passwordless authentication include, e.g., Kerberos-based authentication (possibly using Active Directory), host-based authentication in SSH, traditional “.rhosts” authentication in old rlogin/rsh programs, hard-coding a password in a script (e.g., supplying it on a command line), and fetching a password from a password vault from a script. However, with the SSH protocol, the public key authentication is often the preferred method, because with it one cannot gain access to the private key (the authentication credential in this case) from the second account.
Kerberos authentication can also be used for implementing passwordless logins. Kerberos is described in RFC 4120, The Kerberos Network Authentication Service (V5), Internet Engineering Task Force, July 2005. Kerberos is often used using GSSAPI, which is described in RFC 2743, Generic Security Service Application Program Interface Version 2, Update 1, Internet Engineering Task Force, January 2000.
Some organizations use public key authentication to grant authorizations and access rights to individual users. A user is given authorization to log into certain accounts based on the user's role. For example, an Oracle administrator might be given a private key that authorizes the administrator to log into any Oracle database account in his/her department. When a user's role changes, the old access rights would be removed and new ones might be added in accordance with the new role. Removing the user's access basically means de-authorizing the access.
Another use of public key authentication is to allow administrators to log into shared accounts on jump servers that can then be used to access numerous other systems, such as point-of-sale terminals in a retail environment.
An authorized key means identification of a cryptographic key whose possession authorizes access to a user account on a host.
An identity key means a cryptographic key whose possession authorizes access to a user account on a host. The term is also used for a cryptographic key is configured for an SSH client so that the SSH client may attempt to use it for authentication using public key authentication according to the SSH protocol when logging into an SSH server.
Authorized keys and identity keys are collectively called user keys (or SSH user keys).
Host keys, on the other hand, are used for authenticating hosts (e.g., to prevent man-in-the-middle attacks at protocol level). Host keys do not alone authorize access to any user accounts. Host keys are typically key pairs used for public key cryptography, with the public key called the public host key and the private key called the private host key. An SSH client or SSH server may have known hosts, associations of a host (name or IP address) with a public host key or an identifier for a public key.
A key fingerprint is an identifier for a key that essentially uniquely identifies a key pair. It may be, e.g., a hash value computed from a public key, converted into an ASCII string in some manner. There are several known ways to convert a public key into a key fingerprint, including computing a hash value of an encoded representation of the public key, and representing the hash value in hex. Several different methods for generating fingerprints from a key are in use by different implementations.
Commonly, an authorized key is a public key from a key pair used in public key cryptography, where possession of the corresponding private key authorizes access to the user account (with, e.g., RSA and DSA cryptosystems, the public key uniquely identifies the key pair and therefore the private key). An authorized key may be identified, e.g., by the public key itself or by a key fingerprint computed from the public key. The private key may be configured as an identity key for one or more SSH clients on one or more user accounts on one or more hosts. The same authorized key may be configured as an authorized key for one or more SSH servers on one or more user accounts on one or more hosts.
An SSH client may also access an identity key indirectly, such as through an SSH agent.
Some hosts may not really have the concept of separate user accounts, in which case an authorized key may just grant access to the host (the host is then considered to have an implicit user account on it).
In large organizations, the number of different file transfers and authentications that they manage grows very large, and such organizations sometimes have hundreds of system administrators each managing some hundreds of computers. It is difficult for system administrators, security administrators to keep track of what authorized public key login connections exist, what each connection is used for, and when the connection can/should be removed.
It is currently nearly impossible for organizations to change the authentication keys because of the amount of manual work involved, yet any prudent security practice would require changing authorization keys regularly. Key rotation, renewal, and recertification are terms also used to refer to changing the cryptographic authorization keys, with no substantial difference in meaning.
Furthermore, there is currently no practical way for the organizations to prevent an administrator from copying a private key, and continuing to use the private key after changing roles or leaving the job, and many organizations never remove authorized keys because it is too difficult and expensive or prone to cause service disruption.
There are also other mechanisms for providing automated access in SSH, including host-based authentication, Kerberos authentication, PKI-based public key authentication, hard-coded passwords, and passwords stored in a password vault.
Generally, when automated access has been configured from a first account to a second account, a trust relationship is said to exist from the first account to the second account. Trust relationships are also called connections or automated login connections or passwordless logins in this specification. The first account is often called a source account (on a source host) and the second account is often called a destination account (on a destination host).
Many large enterprises are known to have several hundred thousand to over a million public-private key pairs used as SSH authentication keys. Many large enterprises have sizable teams setting up SSH authentication keys. The combined cost of managing key pairs and authorizations in large enterprises is substantial, and therefore solutions for the more efficiently and more securely managing them are very much needed.
An independent verification of the problem can be found in the paper G. Kent and B. Shestra: Unsecured SSH—The Challenge of Managing SSH Keys and Associations, SecureIT, 2010. It also teaches many of the underlying concepts relating to authorized keys and identity keys and proper (manual) configuration for automated access using SSH. However, it is very limited in its teachings about automating SSH key management or assisting key remediation processes in large environments.